Read the original article here.

---

The Forbidden Code: Meltdown - Reading Forbidden Memory Through CPU Secrets

Welcome to a journey into the fascinating, often hidden, world of low-level system exploitation. In traditional programming courses, you learn about variables, functions, algorithms, and interacting with operating system APIs. But beneath that layer lies the intricate dance of hardware and software, a realm where performance optimizations can inadvertently create vulnerabilities that allow the "forbidden code" to peek into the system's deepest secrets.

One of the most dramatic examples of this is the Meltdown vulnerability. Discovered in 2018, Meltdown wasn't a bug in software logic or a simple buffer overflow; it was a flaw rooted in the fundamental design principles of modern high-performance CPUs. It allowed standard user-level programs, the kind you might write, to read data that should be strictly off-limits – data from the operating system kernel and other running programs. This is the digital equivalent of being able to read everyone else's mail just because you share the same post office.

Meltdown demonstrated that even the seemingly solid security boundaries enforced by hardware privilege levels could be melted away by clever exploitation of performance-enhancing microarchitectural features. Understanding Meltdown provides a crucial look into how side-channel attacks exploit subtle hardware behaviors and how the pursuit of speed can sometimes compromise security.

What is Meltdown? (CVE-2017-5754)

Meltdown (CVE-2017-5754): A hardware-based security vulnerability affecting certain microprocessors, primarily Intel CPUs, some ARM, and IBM Power processors. It exploits a race condition between speculative execution and privilege checks, combined with a cache side-channel attack, to allow unprivileged user-space programs to read arbitrary kernel memory and potentially memory from other processes. It is also known by the identifier Rogue Data Cache Load (RDCL).

Meltdown was disclosed alongside another related vulnerability called Spectre. While both exploit speculative execution, their specific mechanisms and affected hardware differ. Meltdown is particularly devastating because it offers a relatively direct path to reading sensitive memory from the kernel address space, which is mapped into almost every process on vulnerable systems for performance reasons.

Initially, the severity of Meltdown and Spectre was so high that some security researchers reportedly didn't believe the proof-of-concepts were real. The vulnerability was given the name "Meltdown" because, as the researchers put it, it "basically melts security boundaries which are normally enforced by the hardware."

The Battlefield: Modern CPU Architecture - A Programmer's Perspective

To understand how Meltdown works, we need to look at the low-level features modern CPUs and operating systems use to achieve high performance. For the "forbidden code" programmer, these aren't just abstract concepts; they are the building blocks and potential weaknesses to be explored.

1. Virtual (Paged) Memory and Memory Mapping:

   Virtual Memory: An operating system technique that provides each process with the illusion of having exclusive access to a large, contiguous block of memory (its address space), even though the physical memory is shared among multiple processes. This is achieved through paging, where the virtual address space is divided into fixed-size pages mapped to physical memory frames. Memory Mapping: The process of translating virtual memory addresses used by a program into physical memory addresses accessed by the hardware. This mapping is managed by the operating system using page tables, often with hardware support from the CPU's Memory Management Unit (MMU) and Translation Lookaside Buffer (TLB).

   Modern operating systems like Windows, Linux, and macOS use virtual memory extensively. For efficiency, many OS kernels map the entire physical memory and their own kernel code/data into every process's virtual address space. Why? Because this makes system calls (where a user program needs to ask the kernel to do something privileged) much faster. The CPU doesn't need to completely switch contexts and reload page tables just to jump into kernel code; the kernel's code and data are already "visible" in the process's address space, just marked as inaccessible from user mode.

2. Privilege Levels (Protection Domains):

   Privilege Levels (or Rings): Hardware-enforced security mechanisms in CPUs that restrict the operations and memory access capabilities of code running at different levels. Operating system kernels typically run at the highest privilege level (Ring 0 or Supervisor mode), while user applications run at a lower level (Ring 3 or User mode).

   While the operating system maps kernel memory into a user process's address space for performance, it relies on CPU privilege levels to ensure the user process cannot actually read or write that memory directly. Any attempt by user-mode code to access a memory address marked as privileged should trigger an exception (like a segmentation fault), preventing unauthorized access. This hardware-enforced isolation is a cornerstone of modern OS security.

3. Instruction Pipelining and Speculative Execution:

   Instruction Pipelining: A technique where a CPU overlaps the execution of multiple instructions, breaking them down into stages (like fetching, decoding, executing, writing back) and working on different stages of different instructions simultaneously. Speculative Execution: A performance optimization where the CPU predicts the outcome of a branch (like an if statement) and begins executing instructions along the predicted path before the branch condition is finalized. If the prediction is wrong, the CPU discards the results of the speculatively executed instructions and rolls back to the correct path.

   Modern CPUs are designed for speed. They don't just execute instructions one after another; they use complex techniques like pipelining and speculative execution to keep their many internal units busy. Speculative execution is particularly relevant to Meltdown. If a CPU encounters a conditional jump (if (condition) { ... } else { ... }) and the condition isn't ready yet (e.g., it depends on data being fetched from slow memory), the CPU might guess which path is more likely or even start executing both paths simultaneously (eager execution). The key principle is that if the prediction is wrong, the CPU must ensure that the incorrectly executed path leaves no observable side effects.

4. CPU Cache:

   CPU Cache: Small, very fast memory located directly on the CPU chip. It stores copies of frequently accessed data and instructions from main memory (RAM) to reduce the time the CPU spends waiting for data. Accessing data from the cache is significantly faster than accessing it from main memory.

   The CPU cache is critical for performance. When the CPU needs data, it checks the cache first. If the data is there (a "cache hit"), it's retrieved quickly. If not (a "cache miss"), the CPU has to fetch it from main memory, which takes much longer. The cache is dynamic; data is loaded into it based on access patterns (e.g., when an instruction reads from memory).

   Understanding cache behavior, specifically which data is loaded into the cache and how quickly it can be accessed, is fundamental to side-channel attacks.

The Glitch in the Matrix: The Meltdown Technique (CVE-2017-5754)

Meltdown is a classic example of a side-channel attack. It doesn't directly bypass the privilege check or the memory access restrictions. Instead, it exploits a side effect left behind by an operation that should have been prevented by the privilege check, an effect that wasn't properly cleaned up due to speculative execution. The side channel used here is the CPU cache's timing behavior.

Here's how the "forbidden code" leverages Meltdown:

1. Identify the Target: The attacker wants to read the value (let's call it A) from a specific memory location (TargetAddress) in privileged kernel memory. Remember, this memory is mapped into the user process's address space but is marked as inaccessible from user mode.

2. The Forged Instruction Sequence: The core of the attack involves crafting a sequence of instructions that looks something like this (simplified):

   ; Step 1: Attempt to read forbidden data 'A'
   MOV EAX, [TargetAddress] ; This is the forbidden read
   
   ; Step 2: Use the value 'A' (which is unknown) as an offset
   ; to access another memory location in the attacker's control.
   ; Assume BaseAddress is an address controlled by the attacker,
   ; and BaseAddress + A will select one of 256 distinct memory locations
   ; for a byte-sized 'A'.
   MOV EBX, [BaseAddress + EAX*ScaleFactor] ; Access memory based on A
   

   • Note: ScaleFactor is used to ensure each possible value of a byte A (0-255) maps to a distinct memory location within the attacker's controlled BaseAddress range.

3. The Speculative Execution Window: A vulnerable CPU, upon seeing the MOV EAX, [TargetAddress] instruction, might start executing it speculatively for performance, before the privilege check for TargetAddress has completed. During this speculative execution, the value A from TargetAddress is temporarily loaded into a CPU register (EAX in this example).

4. The Dependent Speculative Access: The CPU also speculatively executes the next instruction MOV EBX, [BaseAddress + EAX*ScaleFactor]. Since EAX speculatively holds the value A, this instruction speculatively accesses the memory location at BaseAddress + A*ScaleFactor. As a side effect of this memory access, the data at BaseAddress + A*ScaleFactor is loaded into the CPU cache.

5. The Failed Privilege Check & Incomplete Rollback: Moments later, the privilege check for the initial instruction (MOV EAX, [TargetAddress]) completes and determines that the user process is not authorized to read TargetAddress. The CPU recognizes this and attempts to discard the results of the speculative execution, including the value loaded into EAX. However, on vulnerable CPUs, the side effect of loading BaseAddress + A*ScaleFactor into the cache is not fully undone or invalidated during the rollback process. The cache state persists.

6. The Side-Channel Leak (Cache Timing Attack): The attacker then executes a cache timing attack. They iterate through the 256 possible memory locations starting from BaseAddress (BaseAddress + 0, BaseAddress + 1*ScaleFactor, BaseAddress + 2*ScaleFactor, ..., BaseAddress + 255*ScaleFactor). For each location, they measure how long it takes to access it.

   • Accessing a memory location that is in the cache is very fast.
   • Accessing a memory location that is not in the cache is much slower (requires fetching from main memory).

   Since the speculative execution in step 4 loaded the memory at BaseAddress + A*ScaleFactor into the cache (where A is the forbidden value they are trying to discover), the attacker observes that the memory location corresponding to BaseAddress + A*ScaleFactor is accessed significantly faster than all the others. By identifying which location is fastest, they can determine the value of A.

7. Iteration: This process reads one byte (or even one bit, for fewer timing measurements per byte) of forbidden memory at a time. By repeating this millions of times per second for consecutive memory addresses, the attacker can rapidly extract large amounts of data from the kernel's address space.

Side-Channel Attack: An attack that exploits information gained from the physical implementation of a computer system, rather than relying on theoretical weaknesses in the algorithms or design. Examples include analyzing timing information, power consumption, electromagnetic emissions, or even sound produced by the system.

Cache Timing Attack: A type of side-channel attack that measures the time taken to access memory or execute instructions. By carefully observing how long it takes to access different memory addresses, an attacker can infer which data is currently stored in the CPU cache. This, in turn, can reveal information about recent operations or data values, even if the attacker doesn't have direct access to the data itself.

In essence, Meltdown exploits a fundamental race condition: the speculative execution (speed optimization) happens before the privilege check (security enforcement) fully prevents the operation's side effects from becoming visible via the cache side channel. The CPU's eagerness to get ahead of itself reveals secrets it was explicitly told to protect.

Scope of Operations: Where the Forbidden Code Runs

Meltdown has a wide reach because it targets common architectural features present in many CPUs and exploited by widely used operating systems.

• Affected Hardware:

  • Intel CPUs: Primarily affected. The vulnerability impacts effectively every Intel processor since 1995 that implements out-of-order execution, with the notable exceptions of the Itanium line and older Atom processors predating 2013. This covers the vast majority of desktops, laptops, and servers using Intel chips over two decades.
  • ARM CPUs: Certain specific high-performance ARM cores are affected, most notably the Cortex-A75. Other ARM cores like Cortex-R7, Cortex-R8, Cortex-A8, A9, A15, A17, A57, A72, and A73 are affected by Spectre, but generally not Meltdown. Lower-end cores like Cortex-A53 and A55, common in many mobile devices, are typically not affected by either as they lack out-of-order execution. The Raspberry Pi 4 (Cortex-A72) is affected by Spectre but not Meltdown.
  • IBM Power CPUs: Certain IBM Power processors are also affected by both Meltdown and Spectre.
  • AMD CPUs: AMD microprocessors are explicitly not vulnerable to Meltdown. AMD's architecture handles privilege checks and memory access in a way that prevents the specific race condition and cache side effect exploited by Meltdown. This was a significant point of differentiation at the time of disclosure.
  • Oracle SPARC: Oracle stated that newer V9-based SPARC systems are not affected by Meltdown.

• Affected Operating Systems:

  • Any operating system that maps privileged data (like the kernel's memory) into the address space of unprivileged user processes is potentially vulnerable if running on an affected CPU. This includes most versions of Windows, Linux, macOS, iOS, and potentially Android (depending on the ARM core used).

• Affected Environments:

  • Servers and Cloud Computing: Major cloud providers (like AWS, Google Cloud Platform) were heavily impacted, as they run customer workloads on shared physical servers. Meltdown allows one customer's process to potentially read data from the host kernel or other customer processes running on the same server.
  • Virtual Machines (VMs): While Meltdown cannot typically break out of a fully virtualized VM to read the host's kernel memory or the memory of other VMs, it can allow user processes within a guest VM to read the guest's kernel memory. Container technologies (Docker, LXC, OpenVZ) and paravirtualization (Xen) were also affected, allowing user processes within a container/guest to read the host kernel memory in some configurations.
  • Embedded Devices: Devices using affected ARM or Intel CPUs (smart TVs, mobile phones, networking equipment, etc.) are vulnerable if they allow untrusted code execution. Devices where new code cannot be run are generally considered safe from this specific exploit.

The Fallout: Consequences and Detectability

The primary consequence of a successful Meltdown attack is the unauthorized disclosure of sensitive information. Since the attacker can read any memory mapped into the user process's address space (including the kernel's), they could potentially steal:

• Passwords
• Encryption keys
• Confidential data from other processes running on the system
• Internal kernel data structures

This is particularly dangerous in multi-tenant environments like cloud computing or shared hosting, where an attacker on one virtual machine or container could potentially compromise the host system or other tenants.

Crucially, a Meltdown attack leaves no traces in traditional log files. It exploits microarchitectural side effects, not software bugs or access control list failures. Detecting that an attack happened after the fact is extremely difficult, making it a silent threat.

Countermeasures: The System Strikes Back

Addressing Meltdown required a coordinated effort across operating system developers, CPU manufacturers, and system administrators. The core strategies involved:

1. Software Mitigation (Kernel Page-Table Isolation - KPTI):

   Kernel Page-Table Isolation (KPTI): A software mitigation implemented in operating systems to protect against Meltdown. It works by separating the kernel's page tables from user-space page tables, preventing user-mode code from accessing kernel memory addresses even speculatively. This was originally known as KAISER.

   This is the most common software fix. Instead of mapping the entire kernel address space into every user process's page tables (even if inaccessible), KPTI ensures that kernel memory is mostly mapped only when the system is explicitly executing in kernel mode (e.g., during a system call). When in user mode, the kernel memory mappings are removed or isolated, so even if speculative execution attempts to read from a kernel address, the necessary mapping isn't present in the page tables, preventing the cache side effect that the attack relies on.

   KPTI was implemented in patches for Linux (originally called KAISER, integrated as KPTI), Windows, macOS, iOS, and other affected operating systems.

   Performance Impact of KPTI: This mitigation can introduce performance overhead. The OS now has to switch between different page tables more frequently (between user-space and kernel-space), which involves flushing or switching entries in the CPU's Translation Lookaside Buffer (TLB).

   Translation Lookaside Buffer (TLB): A CPU cache that stores recent translations of virtual memory addresses to physical memory addresses, speeding up memory access. Process-Context Identifiers (PCID): A feature in newer Intel CPUs (since Westmere) that allows the TLB to be tagged with a process ID, enabling the CPU to keep multiple processes' TLB entries simultaneously and switch between them without fully flushing the TLB cache.

   Systems with PCID support suffer less performance degradation from KPTI because the TLB doesn't need a full flush on every user/kernel transition. Older systems without PCID see more significant slowdowns, particularly in workloads involving frequent system calls (like databases, heavy I/O, certain development tasks) or context switches. While early reports suggested up to 30% slowdowns, general desktop use often saw minimal impact, and workloads benefiting from PCID showed smaller impacts.

2. Hardware Redesign: Intel announced that future CPU designs would incorporate hardware changes to mitigate Meltdown (and Spectre v2). These changes aim to prevent the vulnerable speculative execution side effect from occurring or being exploitable, offering a more fundamental fix than the software workarounds. These redesigned processors began appearing in late 2018.

3. Firmware/Microcode Updates: Intel also released microcode (low-level CPU firmware) updates for affected processors dating back to 2013 to help implement software mitigations more effectively or introduce small hardware-level tweaks. Support for older processors was later limited.

In addition to technical patches, general security advice remains relevant: apply software updates promptly, be wary of untrusted code and sources, and use security software. While proof-of-concept exploits exist, widespread "real-world" attacks using Meltdown were not widely reported immediately after disclosure, possibly due to the complexity of the attack and the rapid deployment of patches.

Historical Context: The Road to Meltdown

Meltdown wasn't an isolated discovery; it built upon decades of low-level research and earlier vulnerability findings:

• Early Cache Timing Concerns (1995): Researchers warned about covert timing channels in CPU caches and TLBs as far back as 1995.
• KASLR Development (2012-2014): Operating systems like macOS/iOS and Linux adopted Kernel Address Space Layout Randomization (KASLR) to make it harder for attackers to know the location of kernel code/data in memory, complicating certain exploits.
• Cache Attack Research (2016-2017): Researchers published work demonstrating how cache timing attacks could bypass KASLR and leak information on x86 and ARM CPUs ("ARMageddon").
• KAISER Technique (Mid-2017): Researchers (some of whom later discovered Meltdown) developed the KAISER technique (which became KPTI) as a way to prevent KASLR bypasses by isolating kernel page tables. This work, though initially rejected from a conference, proved to be a critical, albeit partial, mitigation for the yet-undiscovered Meltdown.
• Anders Fogh's Blog Post (July 2017): Security researcher Anders Fogh independently described how speculative execution could be combined with cache timing to read kernel data in a blog post, outlining a mechanism very close to Meltdown.
• Independent Discoveries (2017): Multiple teams (Google Project Zero, Cyberus Technology, Graz University of Technology) independently discovered and reported the Meltdown vulnerability to affected vendors in mid-2017, leading to the coordinated public disclosure in January 2018.

This history shows that the "forbidden code" space is one of continuous exploration, where researchers build upon previous findings to probe the boundaries of system security at the hardware level. KAISER/KPTI is a particularly interesting part of this history, being a mitigation developed before the full extent of the Meltdown vulnerability was known, based on defending against related (though less severe) attacks.

Conclusion: Why Meltdown Matters in Forbidden Code

Meltdown stands as a stark reminder that security is a layered problem, and performance optimizations at one level can unintentionally create vulnerabilities at another. It highlights:

1. The Power of Side Channels: Information leaks aren't always about direct data access. Subtle side effects, like cache state changes, can be just as revealing.
2. Microarchitectural Exploitation: Security isn't just about the documented instruction set or software design; it's also about the undocumented, performance-driven behaviors of the hardware itself. Exploiting these behaviors is a key technique in the "forbidden code" arsenal.
3. The Tension Between Performance and Security: Features like speculative execution, designed purely for speed, can have profound security implications if not carefully implemented with respect to isolation boundaries.
4. The Depth of System Knowledge Required: Understanding vulnerabilities like Meltdown requires deep knowledge spanning CPU microarchitecture, operating system memory management, and low-level programming techniques.

Studying Meltdown isn't just about learning a specific historical bug; it's about gaining insight into the fundamental interactions between hardware and software. It teaches us to look beyond the high-level programming abstractions and consider the underlying machinery – because that's where some of the most impactful, and often "forbidden," security secrets lie hidden. It encourages a mindset of questioning assumptions and probing system behavior at its deepest levels.